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REMARKS 

Claims 34-35, 37-41 , 43-44, 46-47, and 49-53 are pending. Applicant has amended 
claims 34, 37, 41 , and 46, added claim 53, and cancelled claims 36, 42, 45, and 48. 

Applicant's representative would like to thank the Examiner for his consideration 
during the telephone interview of May 3, 2006. During that interview, the Examiner and 
applicant's representative discussed claim 34 and Polish. Applicant has amended the 
claims to clarify the distinction between applicant's invention and Polish as more fully 
described below. 

The Examiner has rejected claims 34-35, 37-39, 41-42, 44, 46-47, and 49-51 under 
35 U.S.C. § 102(e) as being anticipated by Polish and claims 36, 40, 43, 45, 48, and 52 
under 35 U.S.C. § 103(a) as being unpatentable over Polish and Hejna. Applicant 
respectfully submits that the pending claims overcome these rejections. 

Applicant's invention provides a technique for a server to stream a video to a client 
in a way that helps avoid gaps in rendering (e.g., due to buffer underflow) that result when 
the playback speed of the video is increased. (Specification, 24:8:17.) As is common with 
streaming systems, the server streams the video so that the same number of frames (e.g., 
30) is sent for every second of the video regardless of the playback speed. For example, 
the server sends 30 frames per second for a 1X playback speed or a 2X playback speed. 
However, to simulate the 2X playback speed, the server skips every other frame of the 
video so that the 30 frames of one second actually cover two seconds of the video. 
(Specification, 16:9-14.) This skipping of frames is one type of "timeline modification" of 
the video. 

When a user at the client indicates to speed up the playback, the client can 
immediately start simulating the faster playback speed by skipping frames currently in its 
buffer that were sent for the slower playback speed. (Specification, 25:4-6.) The client 
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also notifies the server of the new playback speed. Because the client is skipping frames, 
the buffer will hold less playing time of the video than desired and will more likely lead to a 
gap in rendering. For example, if the buffer can store 5 seconds of playing time at the 
slower playback speed, it would only store 2.5 seconds of playing time when the playback 
speed is doubled. 

According to applicant's invention, when the server receives the notification of the 
greater playback speed, it initially sends the frames of the video for a playback speed that 
is greater than the new playback speed. (Specification, 25:16-22.) The server uses a 
version of the video with a timeline modification as the data for the different playback 
speeds. (Specification, 17:23-18:3.) For example, a version of the video for a 3X playback 
speed will contain every third frame of the video. Thus, the sending of frames for a greater 
playback speed than the new playback will result in a buffer of the receiving client being 
refilled because the frames are rendered at a slower playback speed. The following 
example will help to explain how the buffer is refilled. If a user requests that the playback 
speed be changed from 1X to 2X, the server may initially send the frames for a 3X 
playback speed for 2 seconds. Upon receiving these frames, the buffer will contain 60 
frames representing 6 seconds of the video (i.e., 2 seconds times 3X). Since the client has 
switched to a 2X playback speed, the client will need to display 20 frames per second, 
rather than 30 frames per second, to simulate the 2X playback speed using frames for the 
3X playback speed. Thus, it will take the client 3 seconds to display the 60 frames that 
were received in 2 seconds, which is 6 seconds worth of data. Thus, during the 3 seconds 
it takes to display the 60 frames of 3X data, the client will receive 90 frames for the 2X 
playback speed, which means the buffer will be fuller because it contains 30 frames after 
the 3 seconds. In other words, by sending the video in lower resolution (e.g., 3X to be 
displayed at 2X), the buffer can be aggressively refilled. 

Polish does not send "timeline-modified" video from a server to a client. Rather, 
Polish simply sends the video either more frequent or longer "bursts" depending, in part, 
on the consumption rate of the device that renders the video. There is nothing in Polish to 
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suggest that the server sends anything but the complete video, that is all the frames of the 
video. Since the device that renders the video receives all the frames of the video, the 
device is responsible for simulating whatever playback speed a client selects as described 
at column 6, lines 37-60 of Polish. So, Polish's rendering device performs timeline 
modification, but its server does not. 

Polish refills its buffers by sending "bursts," which include every frame of the video, 
that are either larger or more frequent. Applicant's invention, in contrast, sends video that 
has been "timeline-modified" as is now more clearly recited in the claims. Each of the 
pending claims now recites that the server initially sends data that is "timeline-modified" for 
a playback speed that is greater than the requested playback speed. For example, claim 
53 recites a component that "initially sends frames of the video that are timeline-modified 
for a third playback speed that is greater than the second playback speed [the requested 
playback speed]." As such the claims, the claims are not anticipated or obvious in view of 
Polish or Polish in combination with Hejna. 

The Examiner objected to claim 37 because of a minor typographical error. 
Applicant has amended the claim to correct the typographical error. 
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Based upon the above amendments and remarks, applicant respectfully requests 
reconsideration of this application and its early allowance. If the Examiner has any 
questions or believes a telephone conference would expedite prosecution of this 
application, the Examiner is encouraged to call the undersigned at (206) 359-8548. 

Dated: July 3, 2006 Respectfully submitted, 




Madiricfe J. Pirio 



Registration No.: 33,273 
PERKINS COIE LLP 
P.O. Box 1247 

Seattle, Washington 98111-1247 
(206) 359-8000 
(206) 359-7198 (Fax) 
Attorney for Applicant 
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